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THE PROBLEM - Cache Poisoning 

THE SOLUTION - DNS Security Extensions 

THE STATUS - Where are we today? 



Before We Begin ... 
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A Review of Recursion 



What' s recursion, anyway? 

DNS queries are either recursive or 
nonrecursive 

A recursive query asks the name 
server to do whatever work is 
necessary to find the answer, 
including sending additional 
queries 
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A Review of Recursion (cont.) 




• Who needs recursion? 

Stub resolvers (like the one on your computer) send recursive queries to 
name servers 

Name servers usually send nonrecursive queries to other name servers 

• Who offers recursion? 

External authoritative name servers should not offer recursion at all 
(Assuming they are dedicated to that function) 

Forwarders should only offer recursion to your own internal clients, 
or even only your own internal name servers 












A Brief History of Cache Poisoning 


• What is it? 

• Inducing a name server to cache bogus 
records 

• Made possible by 

Flaws in name server implementations 

Short DNS message IDs (only 16 bits, or 0- 
65535) iL 

• Made easier on J^jL I 

• Open recursive name servers tfg^ 







History continued ... 



Why does it matter? 

A hacker can induce your name server into believing something 
false 

• By caching bogus records 

Your users might connect to the wrong web site and reveal sensitive 
data (passwords, account numbers) there. The "wrong" web site 
might look just like the real web site 

• Your user's email might go to the wrong destination 

Where it might just sit, or it might be copied or modified and then 
sent on 



DNS Message IDs 



A DNS axiom: 

The message ID in a reply must match the message ID in the query 



The message ID is a "random," 16-bit quantity 
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How Random - Not! 




Amit Klein of Trusteer found that flaws in BIND' s 
message ID generator (PRNG) mean that most 
versions of BIND do not use sufficiently random 
message ID's 

If the current message ID is even, the next one is 
one of only 10 possible values 

Also possible, with 13-15 queries, to reproduce 
the state of the PRNG entirely and guess all 
successive message IDs 
















Saved by the Second Law of Thermodynamics 


• To make it more difficult for a hacker to spoof a response, we 
use a random query port 

In addition to a random message ID 

If we use 8K or 16K source ports, we increase entropy by 13 or 
14 bits 

This increases the average time it would take to spoof a 
response substantially 

• However, this is not a complete solution 

Spoofing is harder, but still possible 

Evgeniy Polyakov demonstrated that he could successfully 
spoof a patched BIND name server over high-speed LAN in 
about 10 hours 









The DNS Security Extensions 



• The DNS Security Extensions, or DNSSEC, use asymmetric 
cryptography to 'digitally sign" DNS zone data 

• This provides 

Authentication of DNS data ("Was this data signed by the administrator 
of the zone?") 

Integrity checking of DNS data ("Is this the same data that was signed 
by the administrator of the zone?") 

• To accomplish this, DNSSEC 

Adds several new record types 

Defines new bits in the header of the DNS message (not covered here) 

Defines the process of validation, which recursive name servers can use 
to verify signed data 

Requires new administrative processes 



Public Key Cryptography Illustrated 




Now is the time.. 
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The Key Pair: Public and Private 



In practice 

One key of the pair is kept private 

The other key is made public, by uploading it to a key server, publishing it via a 
directory, or having a certification authority sign it into a certificate 

To send private data, encrypt the data in the recipient' s public key 

Only the recipient, with the corresponding private key, can decrypt it 

To sign data, encrypt the data with your private key 

If the data decrypts with the corresponding public key, retrieved from a 
directory or key server, it came from you 





In DNSSEC, Zones Have Key Pairs 



A signed zone has (at least) one key pair associated 
with it 

The private key is used to sign zone data 

Remote recursive name servers look up the zone' s public 
key to validate signed data in the zone 
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DNSSEC Record Types 


• RRSIG Stores a Resource Record' s digital SIGnature 

• DNSKEY Stores a DNS zone' s public KEY 

• DS Allows a parent zone to vouch for a particular public key 
in a subzone 

• NSEC/NSEC3 Used to send validate-able negative responses 
(not covered) 












More Keys Than a High School Janitor 


• Most zones actually have more than one key pair 

• After a private key has been used a lot, you' re supposed to 
roll over to a new key pair 

All the encrypted material can be used to conduct a cryptanalysis attack 

NIST recommends rolling over once per month 

• If your key (or a hash of it) is published in your parent zone, 
this is a hassle 

You need to communicate with your parent 

You can' t just change keys or you' II invalidate cached data 







The Zone-Signing and Key-Signing Keys 



Consequently, we use two key pairs per zone 

A zone-signing key pair, or ZSK, used to sign all the zone data 

A key-signing key pair, or KSK, used to sign just the zone' s public keys 
The ZSK is rolled over monthly, but this doesn' t require notification of your 
parent, just re-signing with your KSK 
The KSK is rolled over yearly 

Parent zone 




do: 



Key Comparison 

Here' s a chart showing the different keys and what they 



Key Type 


Purpose 


Storage/ Di stri buti on 


Frequency of Use 


ZSK- Private 


Si gns RRsets w t hi n a 

zone to create RRSI G 

records 


Secure offline or secure 
onl i ne storage 


Wienever zone data 

changes or a 

resi gni ng i nterval 

occurs 


ZSK- Publ i c 


Authenticates zone data 
signed by ZSK- private 


DNSKEY RR i n the zone 


Wienever cachi ng 

servers or resol vers 

need to val i date zone 

data 


KSK- Private 


Si gns the DNSKEY RRs for 
aut henti cati on 


Secure offline or secure 
onl i ne storage 


Wienever the ZSK keys 
change 


KSK- Publ i c 


Authenticates the source 
of the zone data 


DNSKEY RR i n the zone; 

Sent to parent for 

aut hent i cat ed del egat i on 

(DS RR) 


Wenever cachi ng 

servers or resol vers 

need to authenticate 

the source of zone 

data 



Keys to the Internet 



What about the root zone and a DS key? 

Seven people have been entrusted with the keys to the 
Internet 



Each smart card holds a fraction of the recovery kev needed 



1 . Britain 

2. U.S. 

3. Burkina Faso 

4. Trinidad and Tobago 

5. Canada 

6. China 

7. Czech Republic 
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What Took You So Long? 



Adoption of DNSSEC has been very slow 

Administering signed zones is cumbersome 

Signing makes zones much (4x-7x) bigger 

Validating signatures requires more resources on recursive name servers 




DNSSEC Validation 



In DNSSEC validation, a recursive name server verifies all of the signatures from the answer 
back to the closest trust anchor (a public key it knows and trusts) 

When DNSSEC is fully deployed, the only trust anchor necessary will be the root' s public key 
Validation can require lots of steps 
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Analysis: Records 



Records Type 



RRSIG 
DS 



Count 



6 
2 



In order to completely validate the chain of RRSIG and DS records (best case): 

- 8 cryptographic hashing operations 

- 6 asymmetric decryption operations 







Analysis: 


Traffic 






1^1 


www.cert.org 


www.isc.org 




Query 1 


49 bytes 


48 bytes 




Response 1 


451 


693 
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49 


36 




Response 2 


602 


891 
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48 
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Query 5 




44 




Response 5 




1504 




Query 6 




44 
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856 




Query 7 




40 
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1342 




Query 8 




40 




Response 8 




1084 




Total 


1 333 bytes 


8875 bytes 

















DNSSEC Accelerating: Zero to 60? Yes! 




• Many top-level zones are signed 

.ag, .be, .bg, .br, .bz, .ch, .cl, .cz, .dk, .fi, .fr, .gi, .hn, .in, .jp, .kg, .lc, .li, .Ik, .me, 
.mn, .my, .na, .nl, .nu, .pm, .pr, .pt, .re, .sc, .se, .tf, .th, .tm, .uk, .us, .vc, .yt 

• Many gTLDs are signed 

.arpa, .asia, .biz, .cat, .com (as of March 31 !), .edu, .eu, .gov, .info, .museum, 
.net, .org 

• The root zone was signed on July 15, 2010 

• OMB mandated that US Federal government agencies sign Internet- 
facing zones by the end of 2009 

About 20% did 












How Are We Doing? 


• Percentage of Internet name servers that are open recursors 

80% (~1 2 million) 

• Percentage of open recursors that are not patched against 
the Kaminsky vulnerability 

4.8% 

• Estimated number of Internet name servers trivially 
vulnerable to cache poisoning 

576,000 









How Are We Doing (The DNSSEC Edition) 



• Growth in the number of DNSSEC-signed zones 
between the 2009 and 2010 DNS Surveys 

4x 

• Percentage of zones signed (in random sample of 
approximately 1 M zones) 

.022% (243 signed 
_zones) 
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Are We There Yet? 




First things first ... 


We need the .au and the second l< 
.net.au etc) to be signed 


evel domains (.com.au, 


^^ 











www.auda.org.au/news-archive 


DNSSEC deployment to commence in Australia 

12 Aug 2010 

.au Domain Administration (auDA) today announced the launch of a phased plan for the 
deployment of Domain Name System Security Extensions (DNSSEC) in the .au domain. 

The plan, developed in conjunction with the .au registry operator, AusRegistry Pty Ltd, outlines a 
five-stage process to introduce DNSSEC into .au and its second-level zones (com.au, net.au etc) 

•The implementation plan, scheduled to commence in September, allows for: 

•experimentation and testing of core systems 

•the gradual "signing" of second level .au domains and the .au TLD 

•a trial implementation for .au domain registrants 

•full production rollout to registrants. 














auDA Response 


17 May 2011 

"We cannot provide you with an update for public 
discussion at this stage." 











A few other things 



• We need better tools to manage our DNS systems 

vi won't cut it anymore 



Better DNS skills 

Do you know how to use dig to test for a DNSSEC 
signed zone? 
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SOA Record 



RRSIG Record 



RRSIG Record 



DNSKEY Record 



DNSKEY Record 





RRSIG Record 




NS Record 




RRSIG Record 




NSEC Record 




RRSIG Record 


hostl 


A Record 


hostl 


NSEC Record 


hostl 


RRSIG Record 


hostl 


RRSIG Record 


www 


A Record 


www 


NSEC Record 


www 


RRSIG Record 



RRSIG Record 



Data 

gm.terencegrey.com please_set_ema il 5 10800 1080 2419200 900 

DNSKEY 5 3 1296000 20110520113817 20110516103817 8083 signed.com.au. 

TIRAJxlLkEOnN/wCnfzJsOLhl+7QNLyLnUKp6XDOOLmTzdNU2wMVCgtpmyaf41TZ2fOYWupq8 

561BsPrfR5vG41yqSVKtmlY5g++dSrvwA9q9leJtRMJglNMAGuu9Bx8ls7sUDV5Q51W18lhOR 

fc33BASSImBsKls9uDVsssTldbMQENSLCMSalkuCY9q8DtM/EXyr9Hb+PlAchimDzYal8KatY2 

9STC7OQz+vgT+aia3EIMa7kagLXGNRkflhOMVqMlESmeEV5XID6aZ7TJ6Y+a0BWTeqkowM 

O7W+0Vxyw41pAyYPINnOs7XzqnblL0iBlloQe6vPj+CuqiKfx0Sw== 

DNSKEY 5 3 1296000 20110520113817 20110516103817 34395 signed.com.au. 

eZx5eafY5+w3jsHvV4kRKs+qiHUKA9hkl6uMBjSBBcj38M2/l76HakERurA2yHBwDkOjzLyAWU 

A8Goo3YKnGvtRrxYmqAaLEN9NJgMbUcr5iuavglvvv7u/aUyMzZOcJcUQEZbRxBQYK4BmcPRh 

XfCmOHEPfS6nRov9jZwObP4= 

257 3 5 

AwEAAcFXZL+8aujUaJGq5yGPCxqlVBQdKllpp4AzEJ2S5zebW+ebrq6TyFQrXDZacJ3o49PrRGq 

25v55QDavCpgvBMlrQMwc75eM7T2rhDolSOmDzkLEItgE5NldClctmGpwaoKvSMHUiQUVrl 

OhMI4Hgq9i + nGd7r6NWYE9nRuuB+orOpT7FloAT3PL8FMlSWImQWPTWECjubDYh6rRHIgqu 

Y4BdTMOQIBBLU5G+vWdivGFUHwLfSA4Q2KeHjTglX5k2cWPcMpSm5j7zoO36/h0mYHKqqi 

dVg+57WzaxcC2/55Adbj+ZB+QN+wuOkdyMifVlrH3k41EIJiTls/xyljovlc= ; key id = 8083 

256 3 5 

AwEAAb2dlEWe7f4LHyMF4q8to/xlqVme5j4ywfEHMCtJPolKRgHle7mp+SxUSKvdHP9ESHbb 

TYhwgh6eAokbGWFSurk/z02xrt2aQJ2+MaNGnUbELsEPaoLqSvkASqtbKaNsll2Nk8aNPokFS 

+TjzBX+AWcFg8unxZrl5ir3o7441hiP ; key id = 34395 

SOA 5 3 28800 20110520113817 20110516103817 34395 signed.com.au. 

IZbqVdOtuhR/7TWEn + mlNLvcJuvBapOOozlCRLuoops3uzut3YS/ynPx99PHOpOB9aLhrzrbPSj31 

3BdhubH3O4UR7+m4gln/R5guVAIRlS2eXhGwNZCidwXZn7hyyo0alYx8QKugola3EpLFs3jab 

UNklbt387gH+talAcHffQ= 

memberl.terencegrey.com 

NSEC 5 3 900 20110520113818 20110516103818 34395 signed.com.au. 

Sj8/4M8TI8HsZVrvaZSSz2WtUmHk6LI3nT7PnTZR6hvujklENXwK7EMbgmJdA/afbRE6nGOJOZS 

D6jG25xxtlsc7BIGQlRkQHLVypiE0SgDCvVOwAQF7qPe8rlriFLHqA2SdhJMN31f6E6OVOqEWl 

DOIZPC3J8MxjKWvfWbQb/Y= 

hostl.signed.com.au NS SOA RRSIG NSEC DNSKEY 

NS 5 3 28800 20110520113818 20110516103818 34395 signed.com.au. 

RYfg+Tjc8W4KINne2LDKOPV8v98iBDMYv4eZvzWE5WZtLR/DpiTghTV3JYsmDFMMPfEQxrda 

G0hdnclsWH8oOoQbvETKNhlwexlDSHDEf5OiBAMXhlsfVlqtKczzRtpuJeGhjqebyHkp6D42nC 

+ PbmahXk6EuvJOI3Me8rmBV+0= 

lO. 1.2.4 

www.signed.com.au A RRSIG NSEC 

A 5 4 28800 20110520113817 20110516103817 34395 signed.com.au. 

k+UHw4sxZIGRUkjOB+n/iUV10lglEEDTbOQJbdPOGxjFvZRQSnfilWqncqsGV7YW/a9zRR6JlK6 

X7Pr+szg/EKIq69HUxVZau82J9pllrPcma2kxDeK+Lb3CZIEMXJg8zkrl/8eHlbHLAvvbi/G4bmgot 

nCeo2a6hxOdM/8RNPM = 

NSEC 5 4 900 20110520113817 20110516103817 34395 signed.com.au. 

rv5 + nhELSMIIjUGakeOwnPM89M45hCBpTF6CK9cOupuc3TihqFaLyflS+mXgjvHY15neASNfFv 

71K2Wrufs9mMhNrTeTg73kV6slrw46DB6PWmV2SBfdV6QzSdlsmJ4FCbPPQozpk4TjNZTpdZ 

yYxEVPRoNKGHWixFoA+EXCZSE = 

lO. 1.2.3 

signed.com.au A RRSIG NSEC 

A 5 4 28800 20110520113817 20110516103817 34395 signed.com.au. 

Sd9aUaDP4f7E6F7kyXM4cm5VDzBYbNvdFpwVSo2/KscbyzNHUlLoJ8VUfdExYDx5+hO+6CaB 

CKTTLWOOWBEIYae2ZRCxqTzOEgs/l3uVJbAMAzfVoFq4m98kD4AANuaGHmBpuQOTetLh8iq 

+ve9Z25B5rE92b/XfdiaKz09NjYM = 

NSEC 5 4 900 20110520113817 20110516103817 34395 signed.com.au. 

IDHiF7aNSwlHm23C50q7QLom + UrveantnJ5eia3c98nNCPWXgzdPspSJaWA5kKUAd6nyWUI 

KCvxOsDAaHPOnuJpXdPXJB8yLlC8+GnGGA4mFOuT5IJv+eVpx3VsjL2QWX7KrRFqRajPEgtfTk 

bpcOG uggS+iAp + 26/zG moAG38= 



